1. Field of the Invention
This is a continuation application of U.S. patent application Ser. No. 10/809,583, filed on Mar. 25, 2004, by Jason M. Bell, now U.S. Pat. No. 7,840,588. This invention relates to the arts of processors for requests to directory servers such as LDAP servers.
2. Description of the Related Art
In the 1970s, many proprietary communications, computing, and data storage systems developed were incompatible with each other. In order for integration of communications and computing technologies to be implemented successfully, standards were needed to allow equipment and systems from different vendors to interoperate. Committees such as the International Standards Organization (“ISO”) and Consultative Committee on International Telephony and Telegraphy (“CCITT”) led the effort which resulted in the Open Systems Interconnect (“OSI”), which defined a seven-layer model of data communication with physical transport at the lower layer and application protocol at the upper layer.
The Defense Advanced Research Project Agency (“DARPA”) sponsored research projects that led the Internet standard effort. The Internet Architecture Board (“IAB”) and its subsidiary, the Internet Engineering Task Force (“IETF”), created guidelines for the Internet using documents called Request for Comments (“RFC”).
After an IETF RFC has been approved, has been implemented and has been used for a period of time, it becomes a standard. The OSI approaches standardization using a formal process, while IETF uses an informal process.
In today's businesses environment, more companies are increasingly relying on networked computer systems to support distributed software. These distributed applications often interact with computers on the same local area network (“LAN”), within a corporate intranet, or anywhere on the worldwide Internet. Because these applications contain vast amount of data such as services, resources, users and other objects accessible from other modules, information needs to be organized in a clear and consistent manner. Much of this data can be shared among many applications, but it must also be protected to prevent unauthorized modification or disclosure of private information. Typically, to improve functionality, ease of use and to enable cost-effective administration, information is collected into a special database, sometimes called a directory.
As the number of applications and different networks has grown, the number of specialized directories has also increased, resulting in separate “islands” of data that cannot be readily shared, and which are difficult to maintain.
“Directory Services” refers to a collection of communications, data storage, and user management functions which allow owners and operators of internetworked computers to manage access to their computer resources, to keep track of the users of a network. Usually, these tasks are performed from one or more administration consoles.
Using Directory Services, an administrator can typically set up and control a set or group of users, and may manage those users (e.g. their privileges, authorizations, identification profiles, etc.) using a directory with a graphical user interface (GUI). Users of computers at remote locations can be added, modified, and managed by a remotely located administrator. In some directory service products, application programs can be distributed electronically and maintained remotely by administrators, as well.
Practically every major supplier of computing platforms, be it operating systems, storage solutions, or entire enterprise computing environments, has a directory service product. However, many of the early directory service products and protocols were also proprietary and incompatible from one vendor to another.
In 1988, the CCITT created the X.500 standard for directory services. X.500 organizes directory entries in a hierarchical name space capable of supporting large amounts of information. To ease the information retrieval process, it also defines the powerful search capabilities. Therefore, X.500 is often used together with add-on modules for interoperation between incompatible directory services because of its functionality and scalability.
X.500 specifies that communication between a directory client and a directory server shall be accomplished using a Directory Access Protocol (“DAP”). However, as an application layer protocol, the X.500 DAP requires the entire OSI protocol stack to operate. This requires more resources than are available in many computing environments. Therefore, an interface to an X.500 directory server that is less resource-intensive was needed.
Lightweight Directory Access Protocol (“LDAP”) is intended to be the solution to solve DAP's resource-intensive disadvantages, and to simplify data access in a complex computing environment. LDAP is an open industry guideline aimed at standardizing the access interface to directories. Its objective is to promote sharing and simplifying management of information regarding individual and entire resource of a company, as well as, access rights of individual resources. LDAP aids the interoperability of applications and information systems by sharing profiles, and improves access security to those applications.
The two main concepts of LDAP is the structure of the directories themselves, and its protocol which is used to access the information stored in those directories. From LDAP's point of view, a directory is essentially a listing of information about objects arranged in some order that gives details about each object. A library card catalog and a city's telephone book are common examples which are often implemented in LDAP format.
A directory is often described as a database, however, it is a specialized database that has characteristics that set it apart from general purpose relational database. An LDAP directory provides search, navigation, localization and authentication management.
An LDAP directory has the following characteristics:                (a) stored data is expected to be accessed by “read” or “search” operations much more often than by “write” updates;        (b) stored data represents relatively “static” information (e.g. telephone numbers, addresses, etc.) which seldom is changed or updated, and as such, its access protocol is optimized for this purpose;        (c) it may not support complex transactions due to its design;        (d) it uses remote access and requires low network bandwidth to access static information;        (e) it classifies information hierarchically;        (f) it utilizes databases as its storage engine;        (g) it may impose limitations in the type of data stored; and        (h) it uses a simplified and optimized access protocol to access information in slim and relatively simple applications.        
Currently, most directory service protocols such as LDAP store static data values for each attribute in entries. Some directory service product suppliers have been able to slightly work around this limitation for very specific cases (e.g. Dynamic groups), but not for regular (e.g. normal) entries. Having this static data limitation proves to be a limiting factor for directories in high volume update scenarios, such as telecommunications. For example, some users of the IBM Directory Server use it to store mobile telephone profile information and locations. This is a heavy burden on the system since the client must constantly poll the server to push its updated information.
A simpler example of the problem can be described in a practical manner as follows. Suppose that a user wishes to create an LDAP directory containing information about each city in their county. Certain data will be relatively static (e.g. Population, GPS coordinates, etc.), but other data is guaranteed to be volatile (e.g. Current temperature). In order to facilitate updating weather information, a client program needs to constantly poll an information source and update the records in the directory far too frequently.
In order to better understand LDAP's umbrella framework and limitations with regard to static and dynamic data, we turn now to FIG. 1. In this illustration of a typical hierarchical data classification model (10), a root level (11) is the topmost entity in the hierarchy. The root level is further organized into geographic regions (12), such as North America, Asia, Europe or even specific countries like United States, Mexico and Canada.
These geographic regions are then further organized into constituent organizations, companies, and/or states (13). These entities are then often broken down into “organizational units” (“OU”) (14), such as departments or divisions, which then include individual unites (15) such as users, and resources (e.g. printers, servers, gateways, etc.)
As such, LDAP's structure is very similar to a typical organizational chart. In addition, each attribute within the framework contains an object identifier (“OID”) that has unique assignment. Each entry in the directory is an instance of a objectclass and comprises an attribute-value pair, and each objectclass contains one or more attributes. There may be multiple values in a directory of the same attribute. The OID associated with each objectclass and with each type of attribute is typically expressed as several numbers separated by a “dot” or period punctuation mark. Each number represents a branch in the hierarchical tree. OID's are typically assigned and maintained by a central registrar in order to assure the uniqueness of each OID's values, and to avoid confusion between information elements which are different but may otherwise assume a similar or equal identifier value.
FIG. 2 depicts an overview (20) of LDAP communications. A remote user or application program (22, 23), such as a bank teller using an LDAP-enabled web browser program (e.g. an LDAP client) may initiate a search for the account number and mailing address for customer A. In this example, customer name, account number and address are three attributes, and the bank teller is requesting the values of attributes:                customername.account_number        
and                customername.mailing_address        
where customername=“customer A”.
The search request is transmitted from the LDAP client to the LDAP directory (24) via a communications network (21), such as the Internet, typically using Transmission Control Protocol/Internet Protocol (TCP/IP) (27, 28, 29).
Once the request reaches the LDAP Server (26), the server will process the request by searching for the information within its directory (25). Customer A's account number and address are retrieved (e.g. “read”), and returned to the requesting user or application program (27, 28) via the communications network (21). The LDAP client receives the search results, and displays the information to the bank teller.
Similarly, the teller can search for other specific data about customer A, such as driver license number or a list of checks cleared within a time frame. With appropriate user authorization, the bank teller may modify the customer's account information within the directory. The modification process, however, takes multiple exchanges within the LDAP protocol to access the directory, which increases network traffic.
FIG. 3 shows a generalized request or “read” sequence (30) under LDAP. In this sequence, time progresses from top to bottom of the figure, and two applications (22, 23) are shown accessing an LDAP server and directory (24). In this diagram, it is important to note that the arrows represent multiple commands, requests, and responses according to the LDAP protocol.
The first application (22), perhaps a web application, is configured to periodically change or update a value for an static attribute stored in the directory (24), while a second application (23) is configured to periodic read or monitor the value of the same static attribute. This value could be, for instance, recent stock prices which are updated in 20 minute intervals.
According to this example, the first web application (22) regularly updates stock prices to the LDAP directory server (24) by first gaining access to the directory through a series of steps (31) to authenticate itself and become authorized to modify values of attributes stored in the LDAP directory (24). After authentication and authorization steps are complete, the first application (22) performs a series of LDAP commands (32) to modify the values (e.g. the stock values) of the stock value attribute for a number of companies (24), such as:                ibm.stock_value        att.stock_value        amzn.stock_value        
for IBM, AT&T and Amazon.com, respectively.
Further according to this example, a second application's (23) purpose is to display the latest stock price to bank employees on a web browser screen. To do so, the second application (23) sends an inquiry to the LDAP directory server (24) and follows a similar authorization/authentication process (33). Once permission is granted by the LDAP server (24), the second application (23) performs a “read” request (34) and receives the values (e.g. stock prices) of the request attributes from the LDAP directory (24), which it then displays on the web browser screen.
Asynchronous to the operations of each other, the first application (22) periodically performs the authentication, authorization, and update processes (36, 35) again to change the values (e.g. stock prices) of the static attributes stored in the directory, and the second application (23) periodically performs the authentication, authorization, and attribute read processes (37, 38) to update the display of the stock price. At any given time, the information displayed by the second application may be aged by 1 to 2 times the length of the update periods of either application (e.g. 20-40 minutes in this example).
As each of these processes actually involves several steps or communication exchanges, limited communications bandwidth can become a problem when either the period of the value updates decreases significantly (e.g. it is updated often), when many simultaneous read requests are being handled (e.g. a lot of clients reading the value), or both. This is not usually a problem for attributes which represent relatively static information (e.g. unchanging or seldom changing data), but a significant problem arises when highly dynamic information is represented within the LDAP directory.
Turning to FIG. 4, the diagram illustrates how the current LDAP process handles more dynamic information (40), such as a stock ticker (e.g. real-time stock values), news headlines, etc. When value (41, 42) of an attribute changes at times t1 and t3, a first application (22) receives or polls a source for the dynamic data, and then must perform the LDAP authentication, authorization, and attribute modification processes to the LDAP directory (24) to update the corresponding attribute values. If the elapsed time between t1 and t3 is relatively short, or if many entries must be updated (or both conditions exist), then the number of steps in the LDAP protocol required to perform the attribute updates and the bandwidth of the communications links between the LDAP server (24) and the server on which the first application (22) is running can become a seriously limiting factor for real-time performance (e.g. updates may not occur in a timely fashion).
Similarly, if the times between consecutive “reads” t2 and t4 of an attribute value are relatively short, even if from different applications or clients, then the number of steps in the LDAP protocol required to perform the attribute reads and the bandwidth of the communications links between the LDAP server (24) and the server on which the requesting applications are running can become a considerably limiting factor for real-time performance (e.g. reads may not occur in a timely fashion).
These performance issues are compounded in situations where an LDAP directory is used to store many attributes which represent data which is changed often or rapidly, when many “reader” applications are configured to access that information, and where communications bandwidth at the LDAP server is limited, often leads to unsatisfactory system performance.
For these reasons, there exists a need in the art for a system and method which addresses real-time handling of dynamic data within LDAP directory services and directory services like it. In addition, there exists a need to support such open directory protocols, such as LDAP, to make it extensible regardless of frequent data value changes.